home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxx / rfc764 < prev    next >
Text File  |  1995-07-25  |  40KB  |  870 lines

  1.                                                                         
  2. IEN 148                                                        J. Postel
  3. RFC 764                                                              ISI
  4.                                                                June 1980
  5.  
  6.                      TELNET PROTOCOL SPECIFICATION
  7.  
  8.  
  9. INTRODUCTION
  10.  
  11.    The purpose of the TELNET Protocol is to provide a fairly general,
  12.    bi-directional, eight-bit byte oriented communications facility.  Its
  13.    primary goal is to allow a standard method of interfacing terminal
  14.    devices and terminal-oriented processes to each other.  It is
  15.    envisioned that the protocol may also be used for terminal-terminal
  16.    communication ("linking") and process-process communication
  17.    (distributed computation).
  18.  
  19. GENERAL CONSIDERATIONS
  20.  
  21.    A TELNET connection is a Transmission Control Protocol (TCP)
  22.    connection used to transmit data with interspersed TELNET control
  23.    information.  TCP and the connection establishment procedure are
  24.    documentented in the ARPA Internet Protocol Handbook.
  25.  
  26.    The TELNET Protocol is built upon three main ideas:  first, the
  27.    concept of a "Network Virtual Terminal"; second, the principle of
  28.    negotiated options; and third, a symmetric view of terminals and
  29.    processes.
  30.  
  31.    1.  When a TELNET connection is first established, each end is
  32.    assumed to originate and terminate at a "Network Virtual Terminal",
  33.    or NVT.  An NVT is an imaginary device which provides a standard,
  34.    network-wide, intermediate representation of a canonical terminal.
  35.    This eliminates the need for "server" and "user" Hosts* to keep
  36.    information about the characteristics of each other's terminals and
  37.    terminal handling conventions.  All Hosts, both user and server, map
  38.    their local device characteristics and conventions so as to appear to
  39.    be dealing with an NVT over the network, and each can assume a
  40.    similar mapping by the other party.  The NVT is intended to strike a
  41.    balance between being overly restricted (not providing Hosts a rich
  42.    enough vocabulary for mapping into their local character sets), and
  43.    being overly inclusive (penalizing users with modest terminals).
  44.  
  45.       *NOTE:  The "user" Host is the Host to which the physical terminal
  46.       is normally attached, and the "server" host is the Host which is
  47.       normally providing some service.  As an alternate point of view,
  48.       applicable even in terminal-to-terminal or process-to-process
  49.       communications, the "user" Host is the Host which initiated the
  50.       communication.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Postel                                                          [Page 1]
  58.  
  59.                                                                         
  60. June 1980                                               RFC 764, IEN 148
  61. Telnet Protocol Specification                                           
  62.  
  63.  
  64.  
  65.    2.  The principle of negotiated options takes cognizance of the fact
  66.    that many sites will wish to provide additional services over and
  67.    above those available within an NVT, and many users will have
  68.    sophisticated terminals and would like to have elegant, rather than
  69.    minimal, services.  Independent of, but structured within, the TELNET
  70.    Protocol various "options" will be sanctioned which can be used with
  71.    the "DO, DON'T, WILL, WON'T" structure (discussed below) to allow a
  72.    user and server to agree to use a more elaborate (or perhaps just
  73.    different) set of conventions for their TELNET connection.  Such
  74.    options could include changing the character set, the echo mode, the
  75.    line width, the page length, etc.
  76.  
  77.    The basic strategy for setting up the use of options is to have
  78.    either party (or both) initiate a request that some option take
  79.    effect.  The other party may then either accept or reject the
  80.    request.  If the request is accepted the option immediately takes
  81.    effect; if it is rejected the associated aspect of the connection
  82.    remains as specified for an NVT.  Clearly, a party may always refuse
  83.    a request to enable, and must never refuse a request to disable, some
  84.    option since all parties must be prepared to support the NVT.
  85.  
  86.    The syntax of option negotiation has been set up so that if both
  87.    parties request an option simultaneously, each will see the other's
  88.    request as the positive acknowledgment of its own.
  89.  
  90.    3.  The symmetry of the negotiation syntax can potentially lead to
  91.    nonterminating acknowledgment loops -- each party seeing the incoming
  92.    commands not as acknowledgments but as new requests which must be
  93.    acknowledged.  To prevent such loops, the following rules prevail:
  94.  
  95.       a.  Parties may only request a change in option status; i.e., a
  96.           party may not send out a "request" merely to announce what
  97.           mode it is in.
  98.  
  99.       b.  If a party receives what appears to be a request to enter some
  100.           mode it is already in, the request should not be acknowledged.
  101.  
  102.       c.  Whenever one party sends an option command to a second party,
  103.           whether as a request or an acknowledgment, and use of the
  104.           option will have any effect on the processing of the data
  105.           being sent from the first party to the second, then the
  106.           command must be inserted in the data stream at the point where
  107.           it is desired that it take effect.  (It should be noted that
  108.           some time will elapse between the transmission of a request
  109.           and the receipt of an acknowledgment, which may be negative.
  110.           Thus, a site may wish to buffer data, after requesting an
  111.  
  112.  
  113.  
  114.  
  115. [Page 2]                                                          Postel
  116.  
  117.                                                                         
  118. RFC 764, IEN 148                                               June 1980
  119.                                            Telnet Protocol Specification
  120.  
  121.  
  122.  
  123.           option, until it learns whether the request is accepted or
  124.           rejected, in order to hide the "uncertainty period" from the
  125.           user.)
  126.  
  127.    Option requests are likely to flurry back and forth when a TELNET
  128.    connection is first established, as each party attempts to get the
  129.    best possible service from the other party.  Beyond that, however,
  130.    options can be used to dynamically modify the characteristics of the
  131.    connection to suit changing local conditions.  For example, the NVT,
  132.    as will be explained later, uses a transmission discipline well
  133.    suited to the many "line at a time" applications such as BASIC, but
  134.    poorly suited to the many "character at a time" applications such as
  135.    NLS.  A server might elect to devote the extra processor overhead
  136.    required for a "character at a time" discipline when it was suitable
  137.    for the local process and would negotiate an appropriate option.
  138.    However, rather than then being permanently burdened with the extra
  139.    processing overhead, it could switch (i.e., negotiate) back to NVT
  140.    when the more "taut" control was no longer necessary.
  141.  
  142.    It is possible for requests initiated by processes to stimulate a
  143.    nonterminating request loop if the process responds to a rejection by
  144.    merely re-requesting the option.  To prevent such loops from
  145.    occurring, rejected requests should not be repeated until something
  146.    changes.  Operationally, this can mean the process is running a
  147.    different program, or the user has given another command, or whatever
  148.    makes sense in the context of the given process and the given option.
  149.    A good rule of thumb is that a re-request should only occur as a
  150.    result of subsequent information from the other end of the connection
  151.    or when demanded by local human intervention.
  152.  
  153.    Option designers should not feel constrained by the somewhat limited
  154.    syntax available for option negotiation.  The intent of the simple
  155.    syntax is to make it easy to have options--since it is
  156.    correspondingly easy to profess ignorance about them.  If some
  157.    particular option requires a richer negotiation structure than
  158.    possible within "DO, DON'T, WILL, WON'T", the proper tack is to use
  159.    "DO, DON'T, WILL, WON'T" to establish that both parties understand
  160.    the option, and once this is accomplished a more exotic syntax can be
  161.    used freely.  For example, a party might send a request to alter
  162.    (establish) line length.  If it is accepted, then a different syntax
  163.    can be used for actually negotiating the line length--such a
  164.    "sub-negotiation" perhaps including fields for minimum allowable,
  165.    maximum allowable and desired line lengths.  The important concept is
  166.    that such expanded negotiations should never begin until some prior
  167.    (standard) negotiation has established that both parties are capable
  168.    of parsing the expanded syntax.
  169.  
  170.  
  171.  
  172.  
  173. Postel                                                          [Page 3]
  174.  
  175.                                                                         
  176. June 1980                                               RFC 764, IEN 148
  177. Telnet Protocol Specification                                           
  178.  
  179.  
  180.  
  181.    In summary, WILL XXX is sent, by either party, to indicate that
  182.    party's desire (offer) to begin performing option XXX, DO XXX and
  183.    DON'T XXX being its positive and negative acknowledgments; similarly,
  184.    DO XXX is sent to indicate a desire (request) that the other party
  185.    (i.e., the recipient of the DO) begin performing option XXX, WILL XXX
  186.    and WON'T XXX being the positive and negative acknowledgments.  Since
  187.    the NVT is what is left when no options are enabled, the DON'T and
  188.    WON'T responses are guaranteed to leave the connection in a state
  189.    which both ends can handle.  Thus, all Hosts may implement their
  190.    TELNET processes to be totally unaware of options that are not
  191.    supported, simply returning a rejection to (i.e., refusing) any
  192.    option request that cannot be understood.
  193.  
  194.    As much as possible, the TELNET protocol has been made server-user
  195.    symmetrical so that it easily and naturally covers the user-user
  196.    (linking) and server-server (cooperating processes) cases.  It is
  197.    hoped, but not absolutely required, that options will further this
  198.    intent.  In any case, it is explicitly acknowledged that symmetry is
  199.    an operating principle rather than an ironclad rule.
  200.  
  201.    A companion document, "TELNET Option Specifications," should be
  202.    consulted for information about the procedure for establishing new
  203.    options.  That document, as well as descriptions of all currently
  204.    defined options, is contained in the TELNET section of the ARPA
  205.    Internet Protocol Handbook.
  206.  
  207. THE NETWORK VIRTUAL TERMINAL
  208.  
  209.    The Network Virtual Terminal (NVT) is a bi-directional character
  210.    device.  The NVT has a printer and a keyboard.  The printer responds
  211.    to incoming data and the keyboard produces outgoing data which is
  212.    sent over the TELNET connection and, if "echoes" are desired, to the
  213.    NVT's printer as well.  "Echoes" will not be expected to traverse the
  214.    network (although options exist to enable a "remote" echoing mode of
  215.    operation, no Host is required to implement this option).  The code
  216.    set is seven-bit USASCII in an eight-bit field, except as modified
  217.    herein.  Any code conversion and timing considerations are local
  218.    problems and do not affect the NVT.
  219.  
  220.    TRANSMISSION OF DATA
  221.  
  222.       Although a TELNET connection through the network is intrinsically
  223.       full duplex, the NVT is to be viewed as a half-duplex device
  224.       operating in a line-buffered mode.  That is, unless and until
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231. [Page 4]                                                          Postel
  232.  
  233.                                                                         
  234. RFC 764, IEN 148                                               June 1980
  235.                                            Telnet Protocol Specification
  236.  
  237.  
  238.  
  239.       options are negotiated to the contrary, the following default
  240.       conditions pertain to the transmission of data over the TELNET
  241.       connection:
  242.  
  243.          1)  Insofar as the availability of local buffer space permits,
  244.          data should be accumulated in the Host where it is generated
  245.          until a complete line of data is ready for transmission, or
  246.          until some locally-defined explicit signal to transmit occurs.
  247.          This signal could be generated either by a process or by a
  248.          human user.
  249.  
  250.          The motivation for this rule is the high cost, to some Hosts,
  251.          of processing network input interrupts, coupled with the
  252.          default NVT specification that "echoes" do not traverse the
  253.          network.  Thus, it is reasonable to buffer some amount of data
  254.          at its source.  Many systems take some processing action at the
  255.          end of each input line (even line printers or card punches
  256.          frequently tend to work this way), so the transmission should
  257.          be triggered at the end of a line.  On the other hand, a user
  258.          or process may sometimes find it necessary or desirable to
  259.          provide data which does not terminate at the end of a line;
  260.          therefore implementers are cautioned to provide methods of
  261.          locally signaling that all buffered data should be transmitted
  262.          immediately.
  263.  
  264.          2)  When a process has completed sending data to an NVT printer
  265.          and has no queued input from the NVT keyboard for further
  266.          processing (i.e., when a process at one end of a TELNET
  267.          connection cannot proceed without input from the other end),
  268.          the process must transmit the TELNET Go Ahead (GA) command.
  269.  
  270.          This rule is not intended to require that the TELNET GA command
  271.          be sent from a terminal at the end of each line, since server
  272.          Hosts do not normally require a special signal (in addition to
  273.          end-of-line or other locally-defined characters) in order to
  274.          commence processing.  Rather, the TELNET GA is designed to help
  275.          a user's local Host operate a physically half duplex terminal
  276.          which has a "lockable" keyboard such as the IBM 2741.  A
  277.          description of this type of terminal may help to explain the
  278.          proper use of the GA command.
  279.  
  280.          The terminal-computer connection is always under control of
  281.          either the user or the computer.  Neither can unilaterally
  282.          seize control from the other; rather the controlling end must
  283.          relinguish its control explicitly.  At the terminal end, the
  284.          hardware is constructed so as to relinquish control each time
  285.  
  286.  
  287.  
  288.  
  289. Postel                                                          [Page 5]
  290.  
  291.                                                                         
  292. June 1980                                               RFC 764, IEN 148
  293. Telnet Protocol Specification                                           
  294.  
  295.  
  296.  
  297.          that a "line" is terminated (i.e., when the "New Line" key is
  298.          typed by the user).  When this occurs, the attached (local)
  299.          computer processes the input data, decides if output should be
  300.          generated, and if not returns control to the terminal.  If
  301.          output should be generated, control is retained by the computer
  302.          until all output has been transmitted.
  303.  
  304.          The difficulties of using this type of terminal through the
  305.          network should be obvious.  The "local" computer is no longer
  306.          able to decide whether to retain control after seeing an
  307.          end-of-line signal or not; this decision can only be made by
  308.          the "remote" computer which is processing the data.  Therefore,
  309.          the TELNET GA command provides a mechanism whereby the "remote"
  310.          (server) computer can signal the "local" (user) computer that
  311.          it is time to pass control to the user of the terminal.  It
  312.          should be transmitted at those times, and only at those times,
  313.          when the user should be given control of the terminal.  Note
  314.          that premature transmission of the GA command may result in the
  315.          blocking of output, since the user is likely to assume that the
  316.          transmitting system has paused, and therefore he will fail to
  317.          turn the line around manually.
  318.  
  319.       The foregoing, of course, does not apply to the user-to-server
  320.       direction of communication.  In this direction, GAs may be sent at
  321.       any time, but need not ever be sent.  Also, if the TELNET
  322.       connection is being used for process-to-process communication, GAs
  323.       need not be sent in either direction.  Finally, for
  324.       terminal-to-terminal communication, GAs may be required in
  325.       neither, one, or both directions.  If a Host plans to support
  326.       terminal-to-terminal communication it is suggested that the Host
  327.       provide the user with a means of manually signaling that it is
  328.       time for a GA to be sent over the TELNET connection; this,
  329.       however, is not a requirement on the implementer of a TELNET
  330.       process.
  331.  
  332.    STANDARD REPRESENTATION OF CONTROL FUNCTIONS
  333.  
  334.       As stated in the Introduction to this document, the primary goal
  335.       of the TELNET protocol is the provision of a standard interfacing
  336.       of terminal devices and terminal-oriented processes through the
  337.       network.  Early experiences with this type of interconnection have
  338.       shown that certain functions are implemented by most servers, but
  339.       that the methods of invoking these functions differ widely.  For a
  340.       human user who interacts with several server systems, these
  341.       differences are highly frustrating.  TELNET, therefore, defines a
  342.       standard representation for five of these functions, as described
  343.  
  344.  
  345.  
  346.  
  347. [Page 6]                                                          Postel
  348.  
  349.                                                                         
  350. RFC 764, IEN 148                                               June 1980
  351.                                            Telnet Protocol Specification
  352.  
  353.  
  354.  
  355.       below.  These standard representations have standard, but not
  356.       required, meanings (with the exception that the IP function may be
  357.       required by other protocols which use TELNET); that is, a system
  358.       which does not provide the function to local users need not
  359.       provide it to network users and may treat the standard
  360.       representation for the function as a No-operation.  On the other
  361.       hand, a system which does provide the function to local is obliged
  362.       to provide the same function as a network user who transmits the
  363.       standard representation for the function.
  364.  
  365.       Interrupt Process (IP)
  366.  
  367.          Many systems provide a function which suspends, interrupts,
  368.          aborts, or terminates the operation of a user process.  This
  369.          function is frequently used when a user believes his process is
  370.          in an unending loop, or when an unwanted process has been
  371.          inadvertently activated.  IP is the standard representation for
  372.          invoking this function.  It should be noted by implementers
  373.          that IP may be required by other protocols which use TELNET,
  374.          and therefore should be implemented if these other protocols
  375.          are to be supported.
  376.  
  377.       Abort Output (AO)
  378.  
  379.          Many systems provide a function which allows a process, which
  380.          is generating output, to run to completion (or to reach the
  381.          same stopping point it would reach if running to completion)
  382.          but without sending the output to the user's terminal.
  383.          Further, this function typically clears any output already
  384.          produced but not yet actually printed (or displayed) on the
  385.          user's terminal.  AO is the standard representation for
  386.          invoking this function.  For example, some subsystem might
  387.          normally accept a user's command, send a long text string to
  388.          the user's terminal in response, and finally signal readiness
  389.          to accept the next command by sending a "prompt" character
  390.          (preceded by <CR><LF>) to the user's terminal.  If the AO were
  391.          received during the transmission of the text string, a
  392.          reasonable implementation would be to suppress the remainder of
  393.          the text string, but transmit the prompt character and the
  394.          preceding <CR><LF>.  (This is possibly in distinction to the
  395.          action which might be taken if an IP were received; the IP
  396.          might cause suppression of the text string and an exit from the
  397.          subsystem.)
  398.  
  399.          It should be noted, by systems which provide this function,
  400.          that there may be buffers external to the system (in the
  401.  
  402.  
  403.  
  404.  
  405. Postel                                                          [Page 7]
  406.  
  407.                                                                         
  408. June 1980                                               RFC 764, IEN 148
  409. Telnet Protocol Specification                                           
  410.  
  411.  
  412.  
  413.          network and the user's "local" Host) which should be cleared;
  414.          the appropriate way to do this is to transmit the "Synch"
  415.          signal described below.
  416.  
  417.       Are You There (AYT)
  418.  
  419.          Many systems provide a function which provides the user with
  420.          some visible (e.g., printable) evidence that the system is
  421.          still up and running.  This function may be invoked by the user
  422.          when the system is unexpectedly "silent" for a long time,
  423.          because of the unanticipated (by the user) length of a
  424.          computation, an unusually heavy system load, etc.  AYT is the
  425.          standard representation for invoking this function.
  426.  
  427.       Erase Character (EC)
  428.  
  429.          Many systems provide a function which deletes the last
  430.          preceding undeleted character or "print position"* from the
  431.          stream of data being supplied by the user.  This function is
  432.          typically used to edit keyboard input when typing mistakes are
  433.          made.  EC is the standard representation for invoking this
  434.          function.
  435.  
  436.             *NOTE:  A "print position" may contain several characters
  437.             which are the result of overstrikes, or of sequences such as
  438.             <char1> BS <char2>...
  439.  
  440.       Erase Line (EL)
  441.  
  442.          Many systems provide a function which deletes all the data in
  443.          the current "line" of input.  This function is typically used
  444.          to edit keyboard input.  EL is the standard representation for
  445.          invoking this function.
  446.  
  447.    THE TELNET "SYNCH" SIGNAL
  448.  
  449.       Most time-sharing systems provide mechanisms which allow a
  450.       terminal user to regain control of a "runaway" process; the IP and
  451.       AO functions described above are examples of these mechanisms.
  452.       Such systems, when used locally, have access to all of the signals
  453.       supplied by the user, whether these are normal characters or
  454.       special "out of band" signals such as those supplied by the
  455.       teletype "BREAK" key or the IBM 2741 "ATTN" key.  This is not
  456.       necessarily true when terminals are connected to the system
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463. [Page 8]                                                          Postel
  464.  
  465.                                                                         
  466. RFC 764, IEN 148                                               June 1980
  467.                                            Telnet Protocol Specification
  468.  
  469.  
  470.  
  471.       through the network; the network's flow control mechanisms may
  472.       cause such a signal to be buffered elsewhere, for example in the
  473.       user's Host.
  474.  
  475.       To counter this problem, the TELNET "Synch" mechanism is
  476.       introduced.  A Synch signal consists of a TCP Urgent notification,
  477.       coupled with the TELNET command DATA MARK.  The Urgent
  478.       notification, which is not subject to the flow control pertaining
  479.       to the TELNET connection, is used to invoke special handling of
  480.       the data stream by the process which receives it.  In this mode,
  481.       the data stream is immediately scanned for "interesting" signals
  482.       as defined below, discarding intervening data.  The TELNET command
  483.       DATA MARK (DM) is the synchronizing mark in the data stream which
  484.       indicates that any special signal has already occurred and the
  485.       recipient can return to normal processing of the data stream.
  486.  
  487.          The Synch is sent via the TCP send operation with the Urgent
  488.          flag set and the DM as the last (or only) data octet.
  489.  
  490.       When several Synchs are sent in rapid succession, the Urgent
  491.       notifications may be merged.  It is not possible to count Urgents
  492.       since the number received will be less than or equal the number
  493.       sent.  When in normal mode a DM is a no operation, when in urgent
  494.       mode it signals the end of the urgent processing (this should
  495.       correspond with the end of Urgent pointer indicated by TCP).
  496.  
  497.          If TCP indicates the end of Urgent data before the DM is found,
  498.          TELNET should continue the special handling of the data stream
  499.          until the DM is found.
  500.  
  501.       "Interesting" signals are defined to be:  the TELNET standard
  502.       representations of IP, AO, and AYT (but not EC or EL); the local
  503.       analogs of these standard representations (if any); all other
  504.       TELNET commands; other site-defined signals which can be acted on
  505.       without delaying the scan of the data stream.
  506.  
  507.       Since one effect of the SYNCH mechanism is the discarding of
  508.       essentially all characters (except TELNET commands) between the
  509.       sender of the Synch and its recipient, this mechanism is specified
  510.       as the standard way to clear the data path when that is desired.
  511.       For example, if a user at a terminal causes an AO to be
  512.       transmitted, the server which receives the AO (if it provides that
  513.       function at all) should return a Synch to the user.
  514.  
  515.       Finally, just as the TCP Urgent notification is needed at the
  516.  
  517.  
  518.  
  519.  
  520.  
  521. Postel                                                          [Page 9]
  522.  
  523.                                                                         
  524. June 1980                                               RFC 764, IEN 148
  525. Telnet Protocol Specification                                           
  526.  
  527.  
  528.  
  529.       TELNET level as an out-of-band signal, so other protocols which
  530.       make use of TELNET may require a TELNET command which can be
  531.       viewed as an out-of-band signal at a different level.
  532.  
  533.       By convention the sequence [IP, Synch] is to be used as such a
  534.       signal.  For example, suppose that some other protocol, which uses
  535.       TELNET, defines the character string STOP analogously to the
  536.       TELNET command AO.  Imagine that a user of this protocol wishes a
  537.       server to process the STOP string, but the connection is blocked
  538.       because the server is processing other commands.  The user should
  539.       instruct his system to:
  540.  
  541.          1. Send the TELNET IP character;
  542.  
  543.          2. Send the TELNET SYNC sequence, that is:
  544.  
  545.             Send the Data Mark (DM) as the only character
  546.             in a TCP urgent mode send operation.
  547.  
  548.          3. Send the character string STOP; and
  549.  
  550.          4. Send the other protocol's analog of the TELNET DM, if any.
  551.  
  552.       The user (or process acting on his behalf) must transmit the
  553.       TELNET SYNCH sequence of step 2 above to ensure that the TELNET IP
  554.       gets through to the server's TELNET interpreter.
  555.  
  556.          The Urgent should wake up the TELNET process, the IP should
  557.          wake up the next higher level process.
  558.  
  559.    THE NVT PRINTER AND KEYBOARD
  560.  
  561.       The NVT printer has an unspecified carriage width and page length
  562.       and can produce representations of all 95 USASCII graphics (codes
  563.       32 through 126).  Of the 33 USASCII control codes (0 through 31
  564.       and 127), and the 128 uncovered codes (128 through 255), the
  565.       following have specified meaning to the NVT printer:
  566.  
  567.          NAME                  CODE         MEANING
  568.  
  569.          NULL (NUL)              0   A no operation
  570.          Line Feed (LF)         10   Moves the printer to the
  571.                                      next print line, keeping the
  572.                                      same horizontal position
  573.          Carriage Return (CR)   13   Moves the printer to the left
  574.                                      margin of the current line.
  575.  
  576.  
  577.  
  578.  
  579. [Page 10]                                                         Postel
  580.  
  581.                                                                         
  582. RFC 764, IEN 148                                               June 1980
  583.                                            Telnet Protocol Specification
  584.  
  585.  
  586.  
  587.          In addition, the following codes shall have defined, but not
  588.          required, effects on the NVT printer.  Neither end of a TELNET
  589.          connection may assume that the other party will take, or will
  590.          have taken, any particular action upon receipt or transmission
  591.          of these:
  592.          
  593.          BELL (BEL)              7   Produces an audible or
  594.                                      visible signal (which does
  595.                                      NOT move the print head)
  596.          Back Space (BS)         8   Moves the print head one
  597.                                      character position towards
  598.                                      the left margin.
  599.          Horizontal Tab (HT)     9   Moves the printer to the
  600.                                      next horizontal tab stop.
  601.                                      It remains unspecified how
  602.                                      either party determines or
  603.                                      establishes where such tab
  604.                                      stops are located.
  605.          Vertical Tab (VT)       11  Moves the printer to the
  606.                                      next horizontal tab stop.It
  607.                                      remains unspecified how
  608.                                      either party determines or
  609.                                      establishes where such tab
  610.                                      stops are located.
  611.          Form Feed (FF)          12  Moves the printer to the top
  612.                                      of the next page, keeping
  613.                                      the same horizontal position
  614.  
  615.       All remaining codes do not cause the NVT printer to take any
  616.       action.
  617.  
  618.       The sequence "CR LF", as defined, will cause the NVT to be
  619.       positioned at the left margin of the next print line (as would,
  620.       for example, the sequence "LF CR").  However, many systems and
  621.       terminals do not treat CR and LF independently, and will have to
  622.       go to some effort to simulate their effect.  (For example, some
  623.       terminals do not have a CR independent of the LF, but on such
  624.       terminals it may be possible to simulate a CR by backspacing.)
  625.       Therefore, the sequence "CR LF" must be treated as a single "new
  626.       line" character and used whenever their combined action is
  627.       intended; the sequence "CR NUL" must be used where a carriage
  628.       return alone is actually desired; and the CR character must be
  629.       avoided in other contexts.  This rule gives assurance to systems
  630.       which must decide whether to perform a "new line" function or a
  631.       multiple-backspace that the TELNET stream contains a character
  632.       following a CR that will allow a rational decision.
  633.  
  634.  
  635.  
  636.  
  637. Postel                                                         [Page 11]
  638.  
  639.                                                                         
  640. June 1980                                               RFC 764, IEN 148
  641. Telnet Protocol Specification                                           
  642.  
  643.  
  644.  
  645.          Note that "CR LF" or "CR NUL" is required in both directions
  646.          (in the default ASCII mode), to preserve the symmetry of the
  647.          NVT model.  Even though it may be known in some situations
  648.          (e.g., with remote echo and suppress go ahead options in
  649.          effect) that characters are not being sent to an actual
  650.          printer, none the less, for the sake of consistency, the
  651.          protocol requires that a NUL be inserted following a CR not
  652.          followed by a LF in the data stream.  The converse of this is
  653.          that a NUL received in the data stream after a CR (in the
  654.          absence of options negotiations which explicitly specify
  655.          otherwise) should be stripped out prior to applying the NVT to
  656.          local character set mapping.
  657.  
  658.       The NVT keyboard has keys, or key combinations, or key sequences,
  659.       for generating all 128 USASCII codes.  Note that although many
  660.       have no effect on the NVT printer, the NVT keyboard is capable of
  661.       generating them.
  662.  
  663.       In addition to these codes, the NVT keyboard shall be capable of
  664.       generating the following additional codes which, except as noted,
  665.       have defined, but not reguired, meanings.  The actual code
  666.       assignments for these "characters" are in the TELNET Command
  667.       section, because they are viewed as being, in some sense, generic
  668.       and should be available even when the data stream is interpreted
  669.       as being some other character set.
  670.  
  671.       Synch
  672.  
  673.          This key allows the user to clear his data path to the other
  674.          party.  The activation of this key causes a DM (see command
  675.          section) to be sent in the data stream and a TCP Urgent
  676.          notification is associated with it.  The pair DM-Urgent is to
  677.          have required meaning as defined previously.
  678.  
  679.       Break (BRK)
  680.  
  681.          This code is provided because it is a signal outside the
  682.          USASCII set which is currently given local meaning within many
  683.          systems.  It is intended to indicate that the Break Key or the
  684.          Attention Key was hit.  Note, however, that this is intended to
  685.          provide a 129th code for systems which require it, not as a
  686.          synonym for the IP standard representation.
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695. [Page 12]                                                         Postel
  696.  
  697.                                                                         
  698. RFC 764, IEN 148                                               June 1980
  699.                                            Telnet Protocol Specification
  700.  
  701.  
  702.  
  703.       Interrupt Process (IP)
  704.  
  705.          Suspend, interrupt, abort or terminate the process to which the
  706.          NVT is connected.  Also, part of the out-of-band signal for
  707.          other protocols which use TELNET.
  708.  
  709.       Abort Output (AO)
  710.  
  711.          Allow the current process to (appear to) run to completion, but
  712.          do not send its output to the user.  Also, send a Synch to the
  713.          user.
  714.  
  715.       Are You There (AYT)
  716.  
  717.          Send back to the NVT some visible (i.e., printable) evidence
  718.          that the AYT was received.
  719.  
  720.       Erase Character (EC)
  721.  
  722.          The recipient should delete the last preceding undeleted
  723.          character or "print position" from the data stream.
  724.  
  725.       Erase Line (EL)
  726.  
  727.          The recipient should delete characters from the data stream
  728.          back to, but not including, the last "CR LF" sequence sent over
  729.          the TELNET connection.
  730.  
  731.       The spirit of these "extra" keys, and also the printer format
  732.       effectors, is that they should represent a natural extension of
  733.       the mapping that already must be done from "NVT" into "local".
  734.       Just as the NVT data byte 104 should be mapped into whatever the
  735.       local code for "uppercase D" is, so the EC character should be
  736.       mapped into whatever the local "Erase Character" function is.
  737.       Further, just as the mapping for 174 is somewhat arbitrary in an
  738.       environment that has no "vertical bar" character, the EL character
  739.       may have a somewhat arbitrary mapping (or none at all) if there is
  740.       no local "Erase Line" facility.  Similarly for format effectors:
  741.       if the terminal actually does have a "Vertical tab", then the
  742.       mapping for VT is obvious, and only when the terminal does not
  743.       have a vertical tab should the effect of VT be unpredictable.
  744.  
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753. Postel                                                         [Page 13]
  754.  
  755.                                                                         
  756. June 1980                                               RFC 764, IEN 148
  757. Telnet Protocol Specification                                           
  758.  
  759.  
  760.  
  761. TELNET COMMAND STRUCTURE
  762.  
  763.    All TELNET commands consist of at least a two byte sequence:  the
  764.    "Interpret as Command" (IAC) escape character followed by the code
  765.    for the command.  The commands dealing with option negotiation are
  766.    three byte sequences, the third byte being the code for the option
  767.    referenced.  This format was chosen so that as more comprehensive use
  768.    of the "data space" is made -- by negotiations from the basic NVT, of
  769.    course -- collisions of data bytes with reserved command values will
  770.    be minimized, all such collisions requiring the inconvenience, and
  771.    inefficiency, of "escaping" the data bytes into the stream.  With the
  772.    current set-up, only the IAC need be doubled to be sent as data, and
  773.    the other 255 codes may be passed transparently.
  774.  
  775.    The following are the defined TELNET commands.  Note that these codes
  776.    and code sequences have the indicated meaning only when immediately
  777.    preceded by an IAC.
  778.  
  779.       NAME               CODE              MEANING
  780.  
  781.       SE                  240 End of subnegotiation parameters
  782.       NOP                 241 No operation
  783.       Data Mark           242 The data stream portion of a Synch
  784.                               This should always be accompanied
  785.                               by a TCP Urgent notification.
  786.       Break               243 NVT character BRK
  787.       Interrupt Process   244 The function IP
  788.       Abort output        245 The function AO
  789.       Are You There       246 The function AYT
  790.       Erase character     247 The function EC
  791.       Erase Line          248 The function EL
  792.       Go ahead            249 The GA signal
  793.       SB                  250 Indicates that what follows is
  794.                               subnegotiation of the indicated
  795.                               option
  796.       WILL (option code)  251 Indicates the desire to begin
  797.                               performing, or confirmation that
  798.                               you are now performing, the
  799.                               indicated option
  800.       WON't (option code) 252 Indicates the refusal to perform,
  801.                               or continue performing, the
  802.                               indicated option.
  803.       DO (option code)    253 Indicates the request that the
  804.                               other party perform, or
  805.                               confirmation that you are expecting
  806.                               the other party to perform, the
  807.  
  808.  
  809.  
  810.  
  811. [Page 14]                                                         Postel
  812.  
  813.                                                                         
  814. RFC 764, IEN 148                                               June 1980
  815.                                            Telnet Protocol Specification
  816.  
  817.  
  818.  
  819.                               indicated option.
  820.       DON'T (option code) 254 Indicates the demand that the
  821.                               other party stop performing,
  822.                               or confirmation that you are no
  823.                               longer expecting the other party
  824.                               to perform, the indicated option.
  825.       IAC                 255 Data Byte 255.
  826.  
  827. CONNECTION ESTABLISHMENT
  828.  
  829.    The TELNET TCP connection is established between the user's port U
  830.    and the server's port L.  The server listens on its well known port L
  831.    for such connections.  Since a TCP connection is full duplex and
  832.    identified by the pair of ports, the server can engage in many
  833.    simultaneous connections involving it's port L and different user
  834.    ports U.
  835.  
  836.    Port Assignment
  837.  
  838.       When used for remote user access to service hosts (i.e., remote
  839.       terminal access) this protocol is assigned server port 23 (27
  840.       octal).  That is L=23.
  841.  
  842.  
  843.  
  844.  
  845.  
  846.  
  847.  
  848.  
  849.  
  850.  
  851.  
  852.  
  853.  
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869. Postel                                                         [Page 15]
  870.